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[57] ABSTRACT 

A context-dependent, multiply binding name resolution sys- 
tem. A name resolver is provided, connected to either a 
requester's system or a receiver's system, or both. Requests 
to a given service or domain name are resolved to the 
appropriate IP address. The intended recipient of the request 
is resolved based upon a combination of one or more 
predetermined criteria, including: information about the 
sender (e.g. geographical location, specific requester 
identity, etc.); information about the intended recipient (e.g. 
load balance at the receiver, type of service, etc.); informa- 
tion contained within the request itself (e.g. type of service 
requested); or other information (time of day, date, random 
selection of recipient, e.g.). The system is implemented in 
hardware and/or software, and the resolution criteria can be 
made interdependent or independent. 

20 Claims, 6 Drawing Sheets 
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SYSTEM FOR CONTEXT-DEPENDENT It would accordingly be advantageous to have a system 

NAME RESOLUTION which takes into account the context of the requester in the 

process of name resolution. 



BACKGROUND OF THE INVENTION 



SUMMARY OF THE INVENTION 



In a network (either Intranet or Internet) system, when a 5 

host wants to communicate with another host or locate a A context-dependent name resolution system is presented, 

service or another host on the network, the address is which implements predetermined criteria for static or 

typically resolved in an absolute manner; that is, the naming dynamic binding of a "name" to any one of several "objects" 

service of the network resolves a given name to a single IP of the same type. Which "object" is selected for the binding 

(Internet Protocol) address. For instance, a domain name 10 is determined by a "name resolver" using context informa- 

service (DNS) caU resolves a name to a single IP address or tion that is explicitly specified by the requestor in a name 

host name on the Internet. resolution lookup call to the "name resolver". The "name 

When there are many connections to a given host or resolver", which is implemented as a server program, stores 

service, the resulting congestion degrades the overall per- a lookup table comprising bindings of a "name" to several 

formance. The service provider may upgrade the service, 15 different instances of an object, along with "policy" infor- 

e.g. to increase its capacity. In this case, in order to keep the mation which defines the criteria for selecting an instance of 

modification of the service transparent to requesting hosts, a the object. For instance, the name may be an internet URL 

demultiplexer may be used, as illustrated by way of example of the form "wwwsun.com", and the resolved to object may 

in FIGS. 1-2. For instance, in FIG. 1 a call to Service 3 will be an IP address of the type 192.146.85.82. Thus the "name 

be uniquely resolved to that service's IP address and trans- 20 resolver" will store the tuple: <www.sun.com ><IP_ 

mitted there accordingly, because there is only a single address_l><IP_address_2>. . . , and will store policies on 

binding in the DNS name resolver to the host of Service 3. which IP address to bind to www.sun.com when a lookup 

In general, in a conventional system such as that illustrated request specifying "www.sun.com" is received by it 

in FIGS. 1, 2 and 2A, there will be a single binding between By enabling multiple binding support in the "name 

a name and an IP address. 25 resolver", several advantages are realized. First, the system 

Yet another alternative is for a special type of enables new resources to be added transparently to the caller, 

demultiplexer, which may monitor the traffic, and from the When a new server is added to distribute the load for one or 

different IP addresses can collect statistics such as response more hosts corresponding to the name "sun.com", for 

time and/or the load on the corresponding IP hosts, and use 3Q instance, the IP address for the new server is simply added 

this information for load balancing by binding a requested to the tuple in the name resolver, along with any desired 

name to an IP address for a host which is less heavily loaded. policy criteria, e.g. to use only between 9 a.m. and 5 p.m. 

If Service 3 is upgraded to include Services 3.1 through Secondly, the fundamental limit to scaling which is inher- 

3.Y, then the demultiplexer is added (see FIG. 2); the ent in today's single binding systems is removed, by 

requesting or DNS resolving host resolves the request as 35 enabling multiple destination servers providing the same 

usual and sends it out over the (Inter- or Intra-)network, but service to be referenced by the same "name" handle by the 

the demultiplexer is interposed between the network and the caller (for example "sun.com"), and the name to be resolved 

service(s), to route the incoming requests to one of the by the name resolver to different physical computers servers, 

services. Note that in this case, there is still a single binding depending upon caller context. Many instances of the name 

between the DNS and the demultiplexer. ^ resolver may be running on different physical computers, 

A problem with this approach is that the demultiplexer and many instances of the services may be running, and the 

acts as a limiting factor on throughput, and additionally requester will access the name resolver closest to him; and 

represents a single source of failure for all of the services me resolved object that is closest to the requester or that can 

that it serves. A mechanism is needed whereby such a critical Dest serve the request (based upon some selected or prede- 

point and bottleneck can be avoided, while still providing 45 termined criteria) will be bound to the request, all transpar- 

access to the services for remote users. ently to the requester. Another advantage of the system of 

An alternative approach to decreasing congestion is & c invention is that it allows resources to be easily repli- 
through DNS spoofing, where the name resolver is fooled cated transparently to the user, eliminating any single point 
into giving out a different name binding, by keeping the of failure m me network or at the service end point. If one 
name resolver updated frequently with a new name resolu- 50 valid destination fails, is not responding or is over-loaded, 
tion binding based on some criteria such as load distribution me name resolver is already capable of binding a "name" to 
on target servers. An example of DNS spoofing is shown in multiple destinations, and the unavailable destination can be 
FIG. 2A, in which a requester 2 issues a request using the disabled in the name resolver's internal tables, using admin- 
name "sun.com", and a DNS lookup 4 looks it up. The host istrative means. 

(1, 2 or 3) to which the names is bound will depend upon 55 Tn e context that may be used as a basis for the binding is 

criteria employed at the destination domain, as determined variable; it may include information about the requester (e.g. 

by DNS spoofing service 6. Such criteria may include load requester IP address, domain name or inferred geographical 

on the hosts, their availability, etc. The DNS spoofing region), about the destination (with similar alternatives), 

service 6 polls the hosts 1-3 periodically or at demand, and about the request itself (e.g. type or quality of service 

binds one of them at a time to the DNS lookup name resolver 60 requested), or about independent information (e.g. time of 

for the name "siin.com". day or time zone of the point of origin of the request). 

to a spoofing service, the criteria used to achieve the DESCRIPTION OF THE DRAWINGS 

binding are not related to the context of the requester; they 

rely only upon information at the destination. Thus, much FIGS. 1-2 A are diagrams of present network systems 

information that could be important in making a binding is 65 used for destination addresses for requests, 

not utilized. In none of the known systems is caller context FIG. 3 is a flow chart illustrating a method according to 

used. the system of the present invention. 
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FIGS. 4 and 5 are diagrams of network systems incorpo- implemented in which the caller simply specifies the name 

rating features of the present invention. of the movie he wants to see, and the name lookup returns 

FIG. 6 in an illustration of the operation of an embodi- to tbe caUcr thc ,p address of a host that is currently able to 

ment of the invention using geography-based resolution XIve th ? nested movie to the caller, 

criteria 5 or 801116 °* me aD ° ve steps may be combined in 

_ _ ' . , - • - . . . more integrated calls to the name resorver. 

FIG. 7 is a diagram depicting zones in which domain In mc prcscnt invcntioil) in to ^ abovc> an 

name service resolve rs and service location resolvers of the additional parameter is passed to the name_bostaddress_ 

invention may be located. lookupO function above (or to all the functions above); this 

r^™™.™™ _ rr*T m „™„ „ ™ m parameter may be called the caller_contexL This caller_ 

DESCRIPTION OF THE PREFERRED 10 fa ^ by ^ ^ ^ ^ {{ ^ 

EMBODIMENTS ip address to use. Thus, the calls would look like: 

A method according to the invention is illustrated in FIG. host_IP_address«name_hostaddress_lookup(host_ 

3, and FIGS. 4-5 shows a suitable systems implementable „ „ handle > caller_context) 

on the Internet or Worldwide Web, the Internet or an 15 CaUer_context is a cookie (or structure) that may include 

Intranet, incorporating features of the name resolution sys- * f ™°° *uch callers IP address, its point of 

, f \ ■ ^ . ° J ongin, the quality of the requested service, or any other 

lem oi me invention. context that might be relevant. These contexts must be well 

Name resolution can include any kind of name resolution specified and their formats) standardized, so that many 

lookup for binding one object to another. This includes different name resolvers can intemperate properly. The 

binding the name of a service to a host computer (or its IP 20 particular caller_context formats and contents selected are 

address) that provides that service, and binding the type of not themselves crucial to the invention, 

service to the name of a service providing that type of The present invention uses requester context-dependent 

service. It also includes resolving a name in one domain to intelligence to determine which of several destination hosts 

another name in the same domain, and to another name in a should be utilized, or in other words, which of several IP 

different domain. For the purposes of this invention, the 25 addresses should be used to resolve a given "name" request, 

terms "service" and "host" can be considered synonymous, The context-dependent intelligence, implemented as hard- 

as can "service location" and "host location". ware or software or a combination of both, allows the 

The system of the invention includes three fundamental "name" resolution to be based upon some context informa- 

features that can be implemented singly or in any combi- tion from the requestor, and/or upon the "name" being 

nation with one another: multiple binding of destination 30 resolved in a context-free manner, but optionally dependent 

addresses to names; caller context name resolution in con- u P° n criteria such as load balancing on the destination, 

nection with such multiple binding and name resolution As shown in FIG. 4, a requesters 100-120, of which there 

policy considerations, i.e. independent criteria upon which mav De arbitrary number, each comprise computers or 

such resolution is based. workstations on a local network, served by a server 150. The 

35 requesters will typically be conventional workstations, per- 

Name Resolution: An Example sonal computers, or any networkable computing device, 

An example of name resolution occurs, for instance, when ™» h loc ? 1 P™**» (130, etc.), memory (140, etc.), mass 

a user wishes to view video, e.g. a movie, on his or her ? l ra Sf ^ , shown > 311(1 netwc * ™™*°™- ™c server 

A i- *• • *u . i . 150 also includes a conventional processor 160. memory 

computer. An application run nine on the computer is used to - „ rt , v ' , 7 , 

, , II * .u u *j* • 40 170, mass storage and necessary connections and control 

make a procedure call to the name resorver to determine , !_ ^ J 

, . , . hardware and software, 

which server can serve a movie, e.g. A . A OA . _ £ . „ 

& A name resolver 180 forms part of the server 150, or may 

service_handle=name_service_lookup("movie") be a mtc unit It be implemented entire i y m 

where the string "movie" is passed to a server, which then softwaiCf ic . „ program modules stored in mass storage 

returns the name of the service providing that movie (or it 45 and/or the me m or it be a stand _ abnc device> 

may return a ImkeJto ^ its own logic or and memory> as desirC(1 

from which the user may be prompted to select one). aBnfGT 150 fe conoccted to a broader nctwork m 

Hie server may, by way of example, return a single such „ the Intcract , an Intranet or WAN (wide-area 

service name (e.g. qutcktune ) m the variable called network), or the Worldwide Web, via a network connection 

"service_handle". Next, the application must determine 50 ( e .g. a T-line) 260. On this network 190 is optionally another 

which server host can provide this service to this client; to name resolver 200 , which may be implemented in the same 

do this, it makes another name resolution call: fashion or diffe rently from the name resolver 180. Name 

host_handle=name_hostname_lookup (service_ resolvers 180 and 200 may both be used, or either may be 

handle) used by itself. (See discussion of FIG. 7, below.) 

and passes it the variable "service_handle" returned by the 55 Destination hosts 210-230 may also be conventional 

previous call. This call returns the name of a server which is computers or workstations with processors (such as 240), 

listed as offering this service. memory (such as 250), mass storage (not shown), network 

The network location of this server must now be connections, etc., as needed to implement conventional 

determined, so that the user's computer or workstation can network functions in addition to the features of the present 

connect to it to get the movie service, and so it makes the 60 invention. 

ca ^ : Referring to the flow chart of FIG. 3, when a requester 

host_IP_address=name„hostaddress_lookup (host__ (such as 100-120) sends a name resolution request to a name 

handle) resolver 180, instead of the single binding of conventional 

and finally obtains an IP address of an appropriate host that systems, the name resolver 180 includes multiple binding 

can provide the movie service to the user. 65 tables and/or functions (implemented by appropriate logic or 

Further calls to this quicktime server may determine a list program modules) to resolve the request to an appropriate IP 

of movies that are available. Alternatively, a design may be address for a destination host (such as 210-230 in FIG. 4). 
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An example of such a multiple binding would be the location (e.g. partially in a local name resolver and partially 

binding of multiple, geographically disparate destinations to in the destination server). 

a single domain name. If, for instance, a user in Germany Alternatively or in addition, criterion B.l may be based 

wishes to access www.sun.com (the WWW server for Sun upon information at the receive end at the time of sending 

Microsystems, Inc.), he or she can simply use the Uniform 5 the request, and resolved at the receiver. 

Resource Locator (URL) "http://www.sun.com"). Thus, the C. Resolution Based Upon Request Contents 

user sends the request from requester (sec FIG. 6), and the type 0 f service requested* 

name resolver determmes that the requester is fa Germany. 2 ! spedficfaformation (or tyU of information) requested; 

(See step 20 in FIG. 3). The selected destination may either _ . . ,. . . i r . ., ' ' 

be in the United States or elsewhere in Europe, since Sun 10 3 " an y ™P""»« '^formation inferred from the 

Microsystems in this example has two "sun.com" locations. reques , an /or 

Since there is a valid European local destination, the name 4 - anv other explicit information obtained from the 

resolver resolves the destination address to sun.com request. 

(Europe), as indicated at box 30 of FIG. 3. This resolved D * Resolution Dependent Upon Other Factors 

destination is then selected for the request packers) (box 40 15 1 • randomly generated selection of destination based upon 

of FIG. 3), and the request is forwarded to sun.com (Europe) qualified list; and/or 

(box 50 of FIG. 3). 2. other independently developed information. 

Following are lists of context-dependent resolution crite- These resolution criteria can be used singly or in any 

ria applicable to the invention and usable at box 30 of FIG. desired combination with one another, as specified by the 

3, where resolution may be based upon requester 20 requester or the administrator of the destination (e.g. server 

information, destination information, request contents, or owner or service provider). For instance, in the example of 

other information: FIG. 6 the resolution of the destination address to sun.com 

A. Resolution Based Upon Requester Information (Europe) could be modified if the load ofsun.com (Europe) 
Examples of manners in which the resolution dependent is larger by some predetermined threshold amount than the 

upon requester information may be carried out include: 25 load at sun.com (USA) — in which case the sun.com (USA) 

1. resolution based upon the domain name of the sender; resolution could override the default sun.com (Europe) 

2. resolution based upon the inferred (looked-up) actual resolution for requesters in Europe, either at all times or only 
geographic region of the sender; durin g P eak European hours, which correspond to off-peak 

3. resolution based upon other geography-related infer- h °™ S ^ ^ United States 

mation of the sender* 30 An extension of this system is in the resolution of services 

4. either directly ascertainable from the request (city/ P rovided at the receiver n& ^ OTk of a re quest. For instance 
country info eg)* and/or a given organization may have many database servers, and 

5. indirectly ascertainable (area code, address, etc.); reqUCSt f £ aCCe *V° g * en infoma * 0Q * av » conventional 

. . / , 1 • r . systems be routed to the same server, because of the single 

6. resolution based upon quahty of service desired by the 35 binding Qature of destination resolution. With multiple 

reques er, an . „ . address resolution binding, multiple database servers (or 

7. resolution based upon requester's time of day or time Qther dcstinatioD hosts) such M 2 l 0 , 270, 280, etc. (see FIG. 

„ „ zo ° c *. „ ^ . . T „ 5) may be made available under a single name, in which case 

B. Resolution Based Upon Destination Information a local resolution acrvcr> ^ w 300 in FIG. 
Examples of manners in which the resolution dependent ^ S , is provided. The server 300 includes tables, program 

upon a specified or intended destination or receiver infer- modules or the ^ ^ desired to resolve a to ^ one 

mation may be earned out include: of to many IP addresses. The selection of a given 

1. resolution based upon the load at the receiver; server to receive a request can depend upon, for example, 

2. resolution based upon the inferred (looked-up) actual load at each of the servers. 

geographic region of the receiver; 45 In general, the resolution systems or subsystems will be in 

3. resolution based upon other geography-related infer- one of three "zones" (see FIG. 7): the sender's zone 1 (up to, 
mation of the receiver: e.g., the sender's firewall or Internet server); the name 

4. either directly ascertainable from the request (city/ resolver system's zone 2 (which may be at a server on the 
country info, e.g.); and/or Internet, or any place outside zone 1 which is not in the 

5. indirectly ascertainable (area code, address, etc.). 50 receiver's system; and the receiver's zone 3, Service loca- 
Criterion B.l can be resolved either based upon informa- tion name resolvers may be in any of zones 1-3; typically, 

lion as perceived at the sender end or based upon informa- destination lookup name resolvers, which may comprise 
tion as it exists at the receiver end, and resolved at the sender multiple-binding domain name services (DNS's), will be in 
end. For example, the sender might frequently send requests either zone 1 or zone 2. It will be understood that zones, for 
to a particular server, service, geographical region or orga- 55 the purpose of this application, are administrative 
nization. In this case, it may be advantageous to regularly boundaries, and need not correlate to actual network bound- 
poll one or more oftenused destinations to determine their aries. 

level(s) of activity. Alternatively, such polling could auto- The present invention can interact with existing systems 

matically be carried out for any destinations for which the in a number of ways. For instance, in secure systems where 

sender determines that its number of requests exceeds a 60 the source address is stripped from the request by a firewall 

certain threshold, or for a top predetermined percentage of (and only, e.g., the domain name remains), then the entire 

requests sent by the requester (e.g. all destinations for which source address would not be used to resolve the destination; 

the number of requests exceeds Nl%, or the top N2 desti- the name resolver is provided with the program instructions 

nations to which the sender makes requests, where Nl and or circuitry to implement this. Note also that the DNS name 

N2 are appropriate predetermined numbers). Polling can be 65 resolution may be a distinct operation from service location, 

implemented as program modules integral to the name and thus the destination can be selected due to a combination 

resolver(s), either entirely in one or in more than one of considerations including source address, requested des- 
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tination address, and request contents, including the type of 
request made or service requested. 

The multiple binding feature of the invention allows a 
single name, Internet address (e.g. URL address such as 
http://www.sun.com) or the like to represent as many actual 
servers (or services) as desired. This has a distinct advantage 
of allowing modifications, upgrades or replications to be 
made to the destination servers) without modification of the 
destination address or service name as used by the requester. 
Such modifications may include adding servers or services, 
or establishing a mirror site at a location geographically near 
a large source of requests, etc. 

There may be security and consistency implications of 
multiple bindings, with concomitant solutions. If a destina- 
tion address can be multiply bound, a name resolver may be 
configured to bind to an incorrect address, either deliberately 
or otherwise. While this may also be a problem with existing 
single binding, multiple binding may complicate detection 
of the problem. Thus, the system of the invention may be 
combined with programs and tables for verification that a 
given binding is valid. Very secure systems may wish to 
limit their multiple binding to a predetermined, fixed num- 
ber of resolution possibilities, or even maintain the current 
system of single binding as far as Internet or Web transmis- 
sion is concerned, and implement multiple binding only 
behind a firewall. Alternatively or in addition, encryption 
and digital signatures may be used to ensure validity of 
bindings, and of modifications or additions to the bindings. 

Variations may be had by designating a given name 
resolution as a default resolution, and utilizing alternative 
resolutions only upon the request meeting predetermined 
criteria (such as load imbalance, geographical distance, 
specific sources of the request, etc.). 

Additional bindings (i.e. additional addresses to which a 
request may resolve) may be added without the requester 
being aware of it, and indeed substitutions may be made at 
any time, again transparently to the requester. 
F. Service Selection Based Upon Caller Context 

The system of the invention may be applied more gener- 
ally to the use of caller context for name resolution. Context 
about the requesting user (e.g. in a variable called "caller__ 
context") can be passed to appropriate functions, such as: 

service_handle-name_service_lookup("movie", 
caller_context) 

host_handle=name_hostname — lookup(service__handle, 
caller_context) 

Here, the function service handle executes a service name 

lookup based upon the input "movie", as well as the infor- 
mation in the variable caller_context, outputting the value 
service_handle. Given this output as input, along with 
(again) caller_context, the function host_handle then 
returns an appropriate host name. 

An example of a possible such situation could result when 
a user desires an encryption service, and several encryption 
policies are available. The service_handle function can be 
configured to return different encryption algorithm services 
based upon the specified destination (which is specified in 
caller__context), or there may be an effective override in the 
caller_context by which the user can select a higher level of 
security. 

In general, as noted above, the invention may be imple- 
mented at the sender's system or at the destination system, 
or indeed at points in between (e.g. at proxy servers). Note 
that single points of failure and bottlenecks are removed 
using the present system, and a truly distributed, multiply 
binding name resolution system is achieved. 
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What is claimed is: 

1. A system for name resolution comprising: 
a first service provider, 

a first requester configured to generate a request which 
5 indicates a destination name of a service; and 

a name resolver interposed between said first service 
provider and said first requester, wherein said name 
resolver is configured to select a destination address 
corresponding to said destination name of said service 
10 from a plurality of destination addresses depending 
upon at least two of either a geographical location of 
said first requester, a load of use of said first provider, 
and/or a time of said request, wherein said geographic 
location of said first requester is specified as a param- 
1S eter within said request. 

2. The system as recited in claim 1, wherein said name 
resolver is configured to select said destination address 
corresponding to said destination name of said service 
depending upon said date of said request and said time of 
said request and wherein said date of said request is specified 

20 as a parameter within said request and said time of said 
request is specified as a parameter within said request. 

3. The system as recited in claim 1, wherein said name 
resolver is further configured to select said destination 
address corresponding to said destination name of said 

25 service depending upon at least one of a quality of said 
service requested by said first requester and a type of said 
service requested by said first requester. 

4. The system as recited in claim 1, wherein said name 
resolver is further configured to select said destination 

30 address corresponding to said destination name of said 
service depending upon at least two of a type of service 
provided by said first server provider, a quality of service 
provided by said first server provider, a date of said service, 
and a time of said service. 

35 5. The system as recited in claim 1, wherein said first 
service provider is included within said first host and said 
first requester is included within said first host. 

6. The system as recited in claim 5, wherein said first 
service provider is included within said first host and said 

40 first requester is included within said first host. 

7. A system for resolving names comprising: 

a name resolving unit coupled to a requester for a service 
and a provider of said service, wherein said name 
resolving unit is configured to select a destination 
45 address corresponding to said destination name of said 
service from a plurality of destination addresses in 
response to a request for said service, and wherein 
said name resolving unit is configured to select said 
destination address corresponding to said destination 
50 name of said service depending upon at least one of 

either a geographical location of said requester, a 
date of said request, and/or a time of said request. 

8. The system as recited in claim 7, wherein said name 
resolving unit is configured to select said destination address 

55 corresponding to said destination name of said service 
depending upon said date of said request and said time of 
said request and wherein said date of said request is specified 
as a parameter within said request and said time of said 
request is specified as a parameter within said request. 

60 9. The system as recited in claim 7, wherein said name 
resolving unit is further configured to select said destination 
address corresponding to said destination name of said 
service depending upon at least one of a quality of said 
service requested by said requester and a type of said service 

65 requested by said requester. 

10. The system as recited in claim 7, wherein said name 
resolving unit is further configured to select said destination 
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address corresponding to said destination name of said 
service depending upon at least two of a type of service 
provided by said provider, a quality of service provided by 
said provider, a date of said service, and a time of said 
service. 

11. The system for resolving names as recited in claim 7, 
wherein said destination name of said service is a domain 
name. 

12. The system for resolving names as recited in claim 7, 
wherein said destination address corresponding to said des- 
tination name of said service is an IP address. 

13. The system for resolving names as recited in claim 7, 
wherein said name resolving unit is configured to look up 
said destination name of said service in a lookup table, 
wherein said plurality of destination addresses are stored in 
said lookup table in connection with said destination name 
of said service. 

14. A method for resolving names comprising: 
receiving a request for a service from a requester wherein 

said request indicates a destination name of said service 
of a provider; 

selecting a destination address corresponding to said 
destination name of said service from a plurality of 
destination addresses in response to said request, 
wherein said selecting said destination address depends 
upon at least two of either a geographical location of 
said requester, a load of use of said provider, and/or a 
time of said request, wherein said geographic location 
of said requester is specified as a parameter within said 
request; and 

transmitting said destination address to said requester. 

15. The method as recited in claim 14, wherein said 
selecting said destination address corresponding to said 
destination name of said service said depends upon said date 
of said request and said time of said request and wherein said 
date of said request is specified as a parameter within said 
request and said time of said request is specified as a 
parameter within said request 

16. The method as recited in claim 14, wherein said 
selecting said destination address corresponding to said 
destination name of said service further depends upon at 
least one of a quality of said service requested by said 
requester and a type of said service requested by said 
requester. 
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17. The method as recited in claim 14, wherein said 
selecting said destination address corresponding to said 
destination name of said service further depends upon at 
least one of a load of use of said provider, a type of service 
provided by said provider, a quality of service provided by 
said provider, a date of said service, and a time of said 
service. 

18. A computer readable storage medium having instruc- 
tions recorded therein, wherein said instructions are oper- 
able to, 

receive a request for a service from a requester wherein 
said request indicates a destination name of said service 
of a provider; 

select a destination address corresponding to said desti- 
nation name of said service from a plurality of desti- 
nation addresses in response to said request, wherein 
said select said destination address depends upon at 
least one of either a geographical location of said 
requester, a load of use of said provider, and/or a time 
of said request, wherein said geographic location of 
said requester is specified as a parameter within said 
request; and 

transmit said destination address corresponding to said 
destination name of said service to said requester. 

19. The computer readable storage medium as recited in 
claim 18, wherein said selecting said destination address 
corresponding to said destination name of said service is 
dependent upon said date of said request and said time of 
said request and wherein said date of said request is specified 
as a parameter within said request and said time of said 
request is specified as a parameter within said request. 

20. The system as recited in claim 18, wherein said 
selecting said destination address corresponding to said 
destination name of said service further depends upon at 
least one of a quality of said service requested by said 
requester, a type of said service requested by said requester, 
a load of use of said provider, a type of service provided by 
said provider, a quality of service provided by said provider, 
a date of said service, and a time of said service. 
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